Subject: re:COS Tables for Subnets with Priority Service

From: "jim (j.) cobban" <[email-masked]>
Date: Thu, 13 Jul 1995 14:27:00 -0400

I am trying to follow up on Gary Dudley's proposal that the cost attributes
of a TG can be used to drive the selection of session routes through a
subnetwork.  Going beyond the theoretical discussion I have examined the
configuration capabilities of a wide variety of products and found that they
are singularly lacking in the ability to explicitly set TG characteristics.
Now I imagine that we are all doing this as a favor to the network
administrator.  In essentially all of the products most or all of the TG
characteristics are either set to values which cannot be overridden by the
administrator, or are at best settable only at a Line level.  I will be
perfectly honest and admit that Nortel's APPN node is one of those which 
derives the TG characteristics from the actual connection characteristics
like most of the other products out there. rather than permit the network
administrator to set these values explicitly.

As a simple example if there is a Frame-Relay interface I have not found any
product which would permit setting the cost/byte or the cost/time parameters
to different values for different connections across that interface.  Most
products don't permit setting them at all.  Now I didn't look into all of the
products in great detail so it is possible that there is a product which
permits defining a single Frame-Relay interface as multiple lines, and
therefore permits setting different TG characteristics on those logically
distinct lines.  What is true is that I have not yet found a single product
which permits explicitly setting the TG characteristics of a defined link
station to values which are different than those of the Line on which it is
located.  The only exception to this is that the AS/400 permits setting the
user defined parameters on a link station basis.

One specific area, which appears to be a universal problem, is trying to set
correct TG characteristics on a connection which appears to start on a
Token-Ring, and may end on a Token-Ring, but in between passes over another
sub-network.  A particular example of such a configuration is one which
involves DLSw, but there are many other data link layer gateways which do
this.  All of the products which I have examined in this area look at the fact
that the link station is connected to them over a Token-Ring and hard-wire
the TG characteristics to capacity=4/16Mb/s, delay=LAN, and costs=0.  However
if the connection is actually going over a WAN through a gateway, then
probably the characteristics should be something like capacity=64Kb/s,
delay=packet, and costs dependent upon the priority.  Most importantly it is
clear that the TG characteristics must be different for different link
connections, even though they are all going through the same TRN port.

TRS may have the theoretical ability to select optimal routes through a
complex network which provides variable class of service, but only if it is
possible to override the appropriate transmission group characteristics in all
products which connect to such networks. 

Jim Cobban   |  [email-masked]                        |  Phone: (613) 763-8013
BNR Ltd.     |  bnrgate.bnr.ca!bcars153!jcobban       |  FAX:   (613) 763-5199
|                                                                             |
|   The opinions expressed are those of the author and do not necessarily     |
|   represent the opinions of Bell-Northern Research or Northern Telecom.     |

---

From: Dave Finnie <[email-masked]>
Date: Mon, 17 Jul 1995 08:18:11 +1000

Jim,

I'm quite surprised by your comments. Surely it's not true that most
APPN implementations don't allow TG characteristic modifications ?

How can some/most of the characteristics hope to be known under all
situations ?

Imagine the following cases:

  * 10Mbps Ethernet bridged to a 4Mbps T/R (Capacity wrong)
  * Routing encapsulation device that transports LAN data over
    WAN (Capacity & propagation delay wrong)
  * Mux transporting leased line data over dial up link (cost wrong)

I'm sure there are others.

Our product makes a best guess at all values, but still allows the NOF
operator to override the configuration if they have a scenario that we
couldn't guess. I naively assumed all other implementations would do
likewise.

If what you say is true, not only does it mean that Gary's proposal
could not possibly work, but surely there will be cases where the
route selection mechanism is choosing the wrong routes ?

What does the TRS team think about these issues ?

Dave